ESM 609
Spring 2008 Module 1 Closure

Question 1:  The text stated that the primary goals of project management are the balance of scope, time, and cost.  Central to accomplishing this balance, it seems, is the formation and maintenance of a great project team.  Since project managers often have little control over resources, what can one offer (besides, perhaps, the promise of future work) to assure the best from the team?  Question 2 (from a different student):  How have you dealt with the frustration of being responsible for the outcomes of projects while probably lacking the full authority to command and control resources/personnel?  What traits or characteristics have helped you the most to that end?

Kinney’s response:  You have identified one of the key problems that Project Managers in non-projectized organizations face.  (We will talk about that in Chapter 4.)  The fact is that most project managers effectively must borrow resources from others and rely upon persuasion (in some cases, coercion) to assure that the efforts of their resources are effectively directed toward the key mission of their projects.  Borrowed resources can be conflicted resources and/or may be insufficiently incentivized to fully support a PM. 

Here, we are beginning to get into organizational and motivational psychology.  I am not sure that there is any single, one-size-fits-all approach to getting the best from teams, because much of it depends on the individual personalities.  Nonetheless, I have witnessed (rarely, but significantly) cases in which leaders – PMs or otherwise – have managed to inspire their teams, and to organize team efforts in a synergistic way that draws the very best from the team members.  In these cases, we’re dealing with intangibles such as vision and the promise of contributing to something worthy that is larger than oneself.

Most projects, ultimately, fall short of inspirational.  Typically, projects implement some solution to some problem, but not in any particularly creative way.  But you still have to maintain some sense of esprit de corps in order to draw the best from the team.

Ultimately, the best way to assure that people stay motivated is for them to feel they make a difference.  Too many leaders – PMs or otherwise – kill rather than nurture motivation through controlling and negative behavior.  The results are never good.  The bottom line is, pay attention not just to your targets but to the people you are depending on to achieve those targets.

In terms of skills, I believe communication skills are paramount.  These communication skills, to be fully mobilized, must engage your technical understanding of the project requirements, your understanding of roles and responsibilities of the team members, your understanding of the project plan and planning process, and your ability to communicate effectively and empathically (but strongly, if needed) with team members.  It’s critical to keep communicating throughout the process.  Silence is not necessarily an indication that all is well.  You have to be proactive about this, and have both the good sense and ethics to raise issues and report bad news early and in a responsible manner.  The great thing about this profession is that to execute it well, you have to be the real deal. 

Question:  Also, in Figure 1-4 of the text the time distribution of project effort is shown with the curve peaking near the end of the time scale.  It seems more and more often recently, projects are focusing effort closer to the beginning of the time scale with increased communication between stakeholders and development of a multi-optioned process flow of project and less emphasis of effort in the actual execution.  Because the chart groups planning, scheduling, monitoring, and control all in one group, is it difficult to see where the peak effort really is.  Does the figure intend to say that planning, then scheduling, then monitoring, then control use increasingly more project effort?  If so, why is there less effort for planning than control? 

Kinney’s response:  I find this figure to be less instructive than others illustrating similar points.  The figure doesn’t consider planning, scheduling, monitoring and control as sequential activities; rather, it is showing that there is a spike in overall project activity after the selection process, which slows after the project is built.  One way to think of the “planning, scheduling, monitoring and control” phase is that it is the PM-centric view of what goes on in the engineering and implementation phases.  To fully understand it – and we will understand it better as the course continues – you have to get into what each of the terms means per the Project Management Body of Knowledge (PMBOK) Guide, and what steps are involved in each.

Overall, the figure suggests, without saying so directly, that the intensity of planning, scheduling, monitoring and control ramps up as the project is “progressively elaborated” (i.e., engineered and packaged) and peaks sometime probably in the early to middle part of implementation (construction).  It is a general figure, because the course of effort can be somewhat elective, and because it will vary from one project to another.  Projects are, after all, unique events.

Question:  In reading chapter 1, I realized two things about my understanding of Project Management.  1: That I take the theory of project management for granted- it was some words that were used all the time in my job and I never realized it was a particular way of doing things as opposed to the only way.  2: That the applicability of project management is much broader than I thought.  I had assumed that project management applied only to engineering projects, as that is where I had heard the words and worked with them.  For example, when I was sitting at the Anchorage Folk Festival, (which comprises two weekends full of performers on one stage plus workshops and performers at venues around town on weekdays, to skim the surface), the emcee was mentioning all the work the Board does to get the festival to happen each year.  He used the words "project management" to describe what the board is involved in every year.  My ears perked up and I realized that I had not understood the scope of project management before taking this class.  I wondered how thoughtfully the emcee had used these words, and if he realized the amount of theory behind them.  Also, I wondered if he realized how aptly he used the words, as I think putting on a festival perfectly fits the definition of project management.

Kinney’s response:  PMI defines a “project” as a “temporary endeavor undertaken to create a unique product, service, or result.”  In my view, a good example of a non-construction project would be a movie or play.  In that world, they don’t use the term “project manager.”  They use the term “producer.”  Really, the producer’s role is the very same thing.  It isn’t necessarily the creative role; it is the role that assures that the components are brought together in a way that enables the intended results to be properly executed, to do so on time, and to keep within budget. 

Another good example is, of course, software development.  Software developers have been very interested in adopting PM techniques over the last several years, to bring discipline to their software developments where, at one time, there was not even a full realization they were executing projects.  These kinds of projects, as we will learn, are overwhelmingly failures in the sense that the vast majority do not get done on time, on budget and/or on the original scope.

Question:  Although you may not know, and it may be particular to my work, it came up in the text and reminded me that I have this unclarity.  What is the difference between a client and a customer?  I suppose different disciplines that use project management have all different names for those who told them to do the work.  Sometimes we confuse the term “client” and “customer,” but I think it is useful to make a distinction.  The client is often the head of an organization you are doing work for, or his/her designee.  The customer is the end user.

Kinney’s response: In Alyeska, I have some current illustrations of the way I view this.  I am working on a project at Pump Station 1 involving installation of a foam system to suppress fires at our crude storage tanks.  The client is the Pipeline Manager, and the customers are the operations personnel at Pump Station 1 – specifically the Control Room Operators and maintenance folks – who would need to use this in the event of an emergency and to maintain it otherwise.  At Pump Station 5, one of my projects is an addition to the sewer treatment plant to resolve several problems.  The client is the Pipeline Manager, or his designee (the Operations and Maintenance Supervisor), but the end customer is really the treatment plant operator.  If he’s not satisfied with the end result, I have failed in the scope.  Linewide, there is a multi-year effort to upgrade oil spill containment sites and boat launches.  Our clients are the Right of Way Manager and the Oil Spill Contingency Manager, but the customers are the local Pipeline and Civil Maintenance Supervisors and their baseline crews who serve as primary standby responders and who also maintain things like this.

Question:  It seems to me that the author has separated meeting the client’s expectations from performance. I work for a consulting engineering firm and if I fail to meet my client’s expectations I am judged to have failed miserably. I am expected to mold the client’s expectations to what is considered by our experts to be the best path. Can you really separate client expectations from performance?

Kinney’s response:  In Project Management, we talk a lot about the “triple constraint” of scope, schedule and budget satisfaction – in other words, we are constrained to perform the required scope satisfactorily, to do so within the schedule limitation and within budget.  To deviate from these is considered a project failure.

Increasingly, over the last few years, I have seen widespread recognition that the “triple constraint” isn’t fully descriptive of project success.  Something else is needed.  Some authors describe that something else as “quality”; others describe it as “customer satisfaction.”  Personally, I like the latter, because quality should be inherent in the scope.  In other words, there must be project performance within an overall framework of customer satisfaction – not only in terms of having the end product meet customer needs, but in terms of the project being done in a collaborative manner that demonstrates to the customer that he or she or they is/are valued.

Since the “client” is essentially the organizational representative of the customer – who I define as the end users – then satisfaction of client expectations is a big component of customer satisfaction.  In that regard, I agree: you shouldn’t expect that client expectations can be separated from performance.

As you allude to, client expectations need to be shaped.  As engineers, we are often aware that the customer is not always technically right, even if we don’t really want to say so directly.  Every project must be developed by progressive elaboration which realistically describes what can be delivered, and how, and it must be agreed to by both the PM and the client. 

There are unfortunately many instances where clients do not act responsibly, and use their power to demand unrealistic and unachievable results, threatening reprisals such as firing if the PM does not deliver.  The Project Management Institute, for one, takes a hard line on this sort of thing, going so far as to say that it’s unethical for a PM to take on a project of that sort, where he or she knows it will fail.  But, for the most part, projects are developed with agreement rather than coercion; failures in those instances are often due to unchallenged assumptions that prove unrealistic.

Question:  I am curious about what methods a project manager would use to ensure team members of separate tasks do not sub-optimize.  I think the terminology in the question confused me a little.  What would sub-optimization result in?  I didn’t think that keeping them from sub-optimizing was beneficial but I probably misinterpreted what sub-optimization means.  Thanks.

Kinney’s response:  This is a great question.  In any organization with different departments and groups, there can be tremendous creative opportunity for supervisors to show excellent performance in some area.  But a closer look may reveal that this performance was achieved at the expense of another group, or that it was achieved with a view to short-term gain that can result in long-term performance degradation.  Among my favorite anecdotes is one about a particular hard-line manager hired by a consulting firm I worked for.  He negotiated his bonuses and packages upfront, and structured his commitment very specifically, that he would cut over $1 million in annual expense from the company operation.  He came in and proceeded to decimate several branches, and cut loose the highly paid “rainmakers” of the company.  Unfortunately for the firm, these were the folks that brought in the business.  When they left, the contracts dried up.  The company lost much more than it ever gained through this approach.  Overall, the blindness of executives who thought this would work was just stunning, and the manager was paid handsomely on the way out.  He demonstrated a form of suboptimizing, which was to pick and choose an achievable metric to excel in, but which was to the detriment of the whole.

More commonly in project contexts, suboptimization occurs in a little less subversive manner.  If a company has an engineering department, it is in effect a functional organization – something we’ll explore later in the course.  This is like a “silo” where you do your thing and often you “throw it over the wall” to the next user.  You have done your part, perhaps executed it very efficiently, but you might not have taken full account of the larger requirements of the project in terms of the actual problem to be solved.  In this manner, you might look good on the surface, but your work has not given full value to the overall end result.

Question:  The text makes mention of using project management to be beneficial due to “the evolution of worldwide competitive markets for the production and consumption of goods and services.”  In your opinion do you consider countries such as China, Taiwan, and other upcoming economic hot zones actually utilize such practices?  Granted the R&D costs in these areas usually tend to be spent in reverse engineering existing technology to produce a cheaper product through both materials and production costs, but even then I don’t exactly see a big push to utilize project management methodologies. 

Kinney’s response:  There is an interesting article in the November 2007 edition of McKinsey Quarterly entitled “Bringing best practice to China” that doesn’t specifically talk about projects.  But the article does discuss at length some of the inefficiencies and opportunities that exist there.  Though not discussed, Project Management is clearly one of the best practices that would improve performance in that environment.  (Go to http://www.mckinseyquarterly.com/home.aspx and register for the free content as directed.  This article is free.)  Since I have no personal familiarity with the Asian economies – all I know is what I have read – I can’t give firsthand testimony on where Asian economies are in project management.  That said, the key faculty members of UAA’s project management department are from Asia and have repeatedly returned to their native countries to provide PM instruction similar to what is delivered in Alaska.  I understand that Project Management is considered much more advanced in the United States than overseas – after all, the modern form of Project Management was created in the USA – and other nations are struggling to catch up.  You might be interested to know that there is a conference scheduled in Anchorage from September 15 to 18, dealing with international project management.  I’d expect Russian and Far East representatives to attend.  This is the 4th International Conference on Project Management (dubbed ProMAC 2008), and the website is at http://promac2008.uaa.alaska.edu/index.htm .  This would be a good one to attend if you have the chance.

Question:  Chapter 1 is pretty straight forward and there isn't a lot of real material to ask about, however the one item I came across that I had a question about is "what the heck is a 'scout-o-rama'?"  (page 9, bottom of first paragraph

Kinney’s response:  Since I am the Cubmaster for my son’s Cub Scout Pack, and a former Boy Scout myself, I can speak to this with some enthusiasm.  A Scout-o-Rama is an annual one day event – usually in late April or early May - where Boy Scouts (11 to 18 years old) and Cub Scouts (7 to 11 years old) throughout the community gather in one place and set up exhibits, mostly for games and fun events, but which often demonstrate outdoor skills such as shelter construction.  It’s really a lot of fun to participate in, and each troop or pack is responsible for their own event.  It used to be the main annual fund-raiser for the Scout organizations, but lately its role in that regard has been de-emphasized.  (Popcorn sales are much more important.)

Question:  Would the reduction in work that occurs in construction during winter months on a major facility construction project alter the life-cycle and effort-cycle curves to have flat spots or dysfunctional dips?  I agree that in a normal project where a contractor could start, work without major interruption, and finish the life-cycle and effort-cycle diagrams would pretty much match the text.

Kinney’s response:  The life cycle illustrations are “typical” and must be altered for situations like you describe, which as you know are very typical for Alaska.  Remember, however, that the curves are also applicable to the entire project life cycle, which goes from inception through feasibility analysis, then to preliminary and final design, then to construction, and finally to turnover and closeout.  The office work – planning, design, etc. – can, of course, proceed pretty efficiently on a year around basis.

Question:  I have currently been given a project (my first) to manage.  How do you keep staff engaged in the earlier stages of the project when effort isn’t as significant, especially on a small budget, low effort project?  Also, how do you know what conflict is good versus bad?  Seems to me that if it is personality driven and if that isn’t managed it could escalate further down the road and into the project.

Kinney’s response:  You have raised some excellent and rather deep questions.  I am by no means the oracle on these issues, but will give my viewpoint for what it’s worth.
Staff engagement at the early stages:  This is a perennial problem that I would guess is underreported and poorly addressed by most companies.  The fact is that the big projects are both more demanding and considered “sexier” than the little ones.  The minor work is often prioritized lower, and there’s no particular rewards that accrue to the staff who work on them.  Therefore people aren’t incentivized adequately to knock out the “nuisance” work.  They may be negatively incentivized – as in, get this thing done or else – but often even this doesn’t happen, because there’s lower visibility.  However, take heart:  these are good jobs to improve your own self discipline on, to demonstrate your proficiency so you can take on the bigger jobs later, and to practice the kinds of persuasive skills and motivational skills it will take to move others to finish their parts of the project.  Those skills are often complemented by the personal touch associated with recognition, thank you’s etc.  When you are really good at this kind of motivation, you can make people want to get it done just to help you out, because you’ve established loyalty through rapport.
Conflict (good and bad):Good conflict happens when you acknowledge fully that a problem exists and you confront the problem, keeping personalities separate from the issue at hand.  In other words, you separate the people from the problem, and you address the people involved constructively.  Bad conflict happens when personalities and egos are in the middle of problem resolution, and emotions get in the way of problem resolution.  It can be made much worse by a bad problem resolution process, in which a problem is addressed by riding roughshod over someone, if someone is ignoring or even belittling contrary views, and especially if there is harassment, intimidation or retaliation in the end.  I have witnessed a lot of this sort of thing.  I can’t think of anything more poisonous or corrosive to an organization.  And you are right – it gets worse the further you get, until an unbelievable amount of effort goes into fixing it (and even then, nothing is ever the same).  Though I may be making it simple, it is avoidable.  It all boils down to being respectful and playing well, the way our mothers taught us.

Question:  I have never heard the different “tiers” to the project level, a.k.a program, project, task, work package, and work unit.  Are these more military terms from project managements roots or are they often used in the everyday work world and I have just missed them? 

Kinney’s response:  I don’t think that “tier” is a standard term per PMI – at least I don’t remember that from my studies getting qualified and ready for the PMP exam.  The authors, however, make a good point in distinguishing program, project, task and work package.
In smaller projects, there is one work package that covers the entire project scope.  In certain very large projects, there are multiple large “tasks” within the overall scope, and it may take several engineering packages to accomplish the entire scope of each task. The project, in turn, may be part of an overall program.

This sort of thing is rare, but we have a good example in Alyeska involving the Strategic Reconfiguration Program.  The overall program is essentially a replacement of legacy equipment, modernizing controls, and enhancing remote operations.  There are a bunch of subsets to the overall program, including oil spill response enhancements to offset what could be viewed as response degradations due to decreased field manning.  Within the overall project, you might have a project dealing with Pump Station 3.  There are a bunch of tasks for that station, with lots of modules and systems involved, so there may be multiple tasks.  Work packages would then be developed to support each task.  (Incidentally, this isn’t necessarily a completely accurate description of the actual work breakdown, but is given as an illustration.) 

See also the discussion in the Spring 2006 closure.